A management system is essential for the efficient operation of any large distributed computer system. A distributed computer system can be managed and monitored at various levels, such as an infrastructure level, a middleware level, and at applications level.
FIG. 1 shows a schematic block diagram of a typical architecture of a management system 100 for a managed system 190. The management system 100 includes a data sensors layer 110 that interfaces with the managed system 190 through native monitoring interfaces 195 to collect data. The data may be static, such as deployment descriptors, or dynamic, such as resource consumption and performance metrics.
The management system 100 further includes a base event generation and data aggregation layer 120 for processing the data collected by the data sensor layer 110 in order to compute aggregate data and/or to generate base events. The base events and aggregate data may be stored in a data repository 150.
The management system 100 further includes an event composition and filtering layer 130, which filters and composes events based on pre-defined rules to generate composite events. Finally, the management system 100 includes different system management applications 140, such as visualization, problem determination, planning, and other analytic applications, also using the data in the repository 150.
The management system 100 shown in FIG. 1 is driven by the data collected by data sensors 110. Each data sensor 110 is designed to interact with a specific component in the managed system 190, and is based on the nature and type of interaction that is meaningful and feasible for the given managed system component.
Semantic tags are used to give “meaning” to data. Semantics are traditionally designed into the higher layers of the management system 100, those being the base event generation and data aggregation layer 120, the event composition and filtering layer 130 and the system management applications 140. For example, consider the case where the data sensor layer 110 includes a data sensor that periodically checks the status of a port in the managed system 190. The output of that data sensor is a bit, with a “0” signifying that the port is “down” and a “1” signifying the port is “up”. The semantics of what the output of that data sensor represents is designed into the higher level layers 120, 130 and 140. Consider further the case where the data sensor layer 110 includes a second sensor which checks if the queue size of the managed system 190 is within tolerable limits. That second sensor outputs a “1” if the queue size is within tolerable limits, and a “0” otherwise. Even though both data sensors output a “0” or a “1”, the meanings of those output bits are different for each sensor. The higher level layers 120, 130 and 140 of the management system 100 have to differentiate the data collected from the different data sensors. Thus, programming is required at most of the layers 120, 130 and 140 of the management system 100 to interpret the data collected by the data sensors 110. For example, when modules are added in the data sensor layer 110, the higher layers 120, 130 and 140 need to be reprogrammed to “understand” the meaning of data output by such added modules. This “lack of localization” makes maintaining and enhancing the traditional management system 100 complex.
An article entitled “Learning Domain Ontologies from Document Warehouses and Dedicated Web Sites” by R. Navigli, and P. Velardi, published in Computational Linguistics, MIT press, (50)2, 2004 discloses the use of ontologies to express the inter-relationships between symbolic entities. Ontologies are often human created, though automated methods of building ontologies exist. One such an automated method of building ontologies is disclosed in R. Navigli, P. Velardi, A. Cucchiarelli, and Francesca Neri, “Automatic Ontology Learning: Supporting a Per-Concept Evaluation by Domain Experts,” Proc. ECAI, 2002.
To illustrate the use of ontologies to express the inter-relationships between symbolic entities, consider as for example a symbolic entry “leukaemia”, which is a type of cancer. However, the symbolic entity “leukemia” is just that, a symbolic entity, and a knowledge source (the ontology) is required for a computer to associate the symbolic entry “leukaemia” with a type of cancer. Within the context of natural language processing, bioinformatics, and other text processing domains, a considerable amount of work has been performed on ontologies. From another perspective, ontology is to natural language what objects are to object oriented computer programming. In object oriented computer programming there are “classes” which contain the data and the “methods” that operate on the data. Classes may be sub-classes of, or children of, other classes. Accordingly, a relationship between classes is established. However, in both the case of ontologies and in the case of object oriented computer programming the relationship is separate from the representation of the symbolic entity. For example, the fact that a class called “myclass” and another class called “cat” are related cannot be inferred from the representation of the classes (myclass and cat in this example). There has to be a separate registration of the fact that cat is a sub-class of myclass. Similarly the representations of “leukaemia” and “cancer” do not in any way reveal the inter-relationship between the two symbolic entities. The inter-relationship is separate from the representations of the symbolic entities themselves.
A need therefore exists for an improved management system in which modules can be added to a data sensor layer without the need to reprogram layers in which the data output by the new modules is used in order for those layers to “understand” the meaning of the data output by the added modules.